1. Field of the Invention
The present invention relates to content transmission devices and content transmission methods for transmitting content, which is encrypted for copyright protection or other purposes, and computer programs used therewith. In particular, the present invention relates to a content transmission device and method for use in executing an encrypted content transmission procedure between DTCP (Digital Transmission Content Protection) compliant devices, and to a computer program used therewith.
More specifically, the present invention relates to a content transmission device and method for transmitting content in a form in which attribute information and copy control information concerning the content are inserted in each packet, and a computer program used therewith. In particular, the present invention relates to a content transmission device and method for transmitting content in a form in which attribute information and copy control information concerning the content are inserted into each packet in a form that is not dependent on the format of the content, and a computer program used therewith.
2. Description of the Related Art
With widespread use of information technology, most audio-visual (AV) content has become digitized, and digital content recording/playback media, such as compact discs (CDs) and digital versatile discs (DVDs), have become widely used. Also, recently, devices for digitally recording content, such as hard disk drive (HDD) recorders and DVD recorders, have started to be used even in homes. In addition, distribution and delivery services of content such as video and audio via networks have become popular. Accordingly, content is delivered between remote terminals via a network without transfer of a medium such as a CD or a DVD.
Obviously, in the case of Japan, in Japanese Copyright Law, AV content can be protected as a copyrighted work from unauthorized use such as unauthorized duplication and alteration. In Japanese Copyright Law, under Article 30, it is permissible for a user to reproduce a work forming the subject matter of copyright for the purpose of personal use, family use or other similar uses within a limited circle, while, under Article 49(1), it is prohibited to use a reproduction except for private use.
However, for digitized content, unauthorized manipulations, such as copying and alteration, can be easily performed. Accordingly, not only from a viewpoint of development of laws but also from a technical viewpoint, protection against unauthorized use is necessary while permitting personal or family use of content. In particular, in Japan, with the approaching cessation of analog terrestrial television broadcasting in 2011, replacement of digital terrestrial television receivers for analog broadcast television receivers is rapidly proceeding. Accordingly, for digitalization of AV content in homes, it is very necessary to technically realize content protection.
Many technologies intended to protect copyright of digital content have been developed. For example, industry standards concerning protection of digital transmission content include the Digital Transmission Content Protection (DTCP) developed by the Digital Transmission Licensing Administrator (DTLA). DTCP prescribes a mechanism for content transmission in a copyright-protected form (see, for example, Digital Transmission Content Protection Specification Volume 1 (Informational Version), Revision 1.4) (http://www.dtcp.com/).
DTCP includes provisions concerning an authentication protocol in content transmission between devices and a transmission protocol for encrypted content. In brief, a DTCP compliant device may not send, to the exterior, in an uncompressed state, easy-to-manipulate compressed content complying with a standard such as MPEG (Moving Picture Experts Group). Key exchange necessary for decrypting encrypted content is performed in accordance with a predetermined mutual authentication and key exchange algorithm, that is, the Authentication and Key Exchange (AKE) algorithm. In addition, the range of devices which use AKE commands to exchange keys is restricted.
A server (DTCP_Source) that is a content provider and a client (DTCP_Sink) that is a content receiver share a key after performing an authentication procedure by transmitting and receiving AKE commands, and use the key to encrypt a transmission path before performing content transmission. Accordingly, it is difficult for a client to acquire an encryption key unless the client and the server succeed in mutual authentication with each other. Thus, it is difficult for an unauthorized client to enjoy content. Moreover, by limiting the number and range of devices that can transmit and receive AKE commands, use of the content can be limited to personal or family use according to Japanese Copyright Law.
DTCP primarily makes prescriptions concerning transmission of digital content on a home network in which an IEEE (Institute of Electrical and Electronics Engineers) 1394 bus is used as a transmission path. However, recently, as is typified by the Digital Living Network Alliance (DLNA), there has been an increasing trend toward distributing digitized AV content in a home by using an Internet Protocol (IP) network. Accordingly, development of DTCP technology for IP networks, that is, DTCP mapping to IP (DTCP over Internet Protocol), is in progress. Regarding many home networks, it is pointed out that unauthorized copying and alteration of content may occur when the home networks are connected to external IP networks such as the Internet via routers. It is an urgent need that, by establishing DTCP-IP technology, flexible and efficient use of the digital content is achieved by using an IP network while protecting digital content.
Basically, DTCP-IP is included in DTCP standards and is similar to DTCP technology, and is a technology in which DTCP technology is implanted in the IP network. However, DTCP-IP differs from the original DTCP prescribed on the IEEE 1394 basis in that DTCP-IP uses an IP network and that DTCP-IP uses protocols such as the Hyper Text Transfer Protocol (HTTP) and the Real Time Protocol (RTP). In addition, in DTCP-IP, various types of devices, mainly such as personal computers, are connected to the IP network, so that there is a high possibility that data may be easily sniffed and altered. Accordingly, DTCP-IP prescribes a further method for transmitting content through a network while protecting the content (see, for example, DTCP Volume 1 supplement E Mapping DTCP to IP (Informational Version), Revision 1.1 (http://www.dtcp.com/).
Content transmission complying with DTCP-IP is described below. When content transmission is performed by using the HTTP protocol between source and sink devices complying with DTCP-IP, encrypted communication is performed while changing a content key in the middle of transmission of a very long byte stream such as a Transmission Control Protocol (TCP) stream, and a content key confirmation procedure is performed when an encrypted content decrypting process and another content process are implemented. In addition, a TCP connection is established for each of procedures of mutual authentication and key exchange (AKE), content transmission, and content key confirmation.
Specifically, when an AKE procedure is successfully performed, the DTCP_Source device and the DTCP_Sink device can share authentication key Kauth. The DTCP_Source device generates seed key Kx, which serves as a content key seed, uses authentication key Kauth to encrypt the generated key, and sends the encrypted key to the DTCP_Sink device. After using a random number to generate nonce Nc, the DTCP_Source device generates content key Kc on the basis of seed key Kx, nonce Nc, and an extended encryption mode indicator (E-EMI) representing an encryption mode. After using content key Kc to encrypt content requested by the DTCP_Sink device, the DTCP_Source device transmits, to the sink device, on a TCP stream, packets in each of which a header includes the encrypted content, nonce Nc, and the E-EMI. By extracting nonce Nc and the E-EMI from the TCP stream, the DTCP_Sink device can use the extracted items and key Kx to similarly calculate content key Kc, and can decrypt the encrypted content.
In such a manner, in DTCP-IP, by performing authentication between DTCP compliant devices, sharing a key between the devices which have successfully completed DTCP authentication, and performing encryption and decryption when content is transmitted, a content transmission technique which is also secure on an IP network and which prevents content from being sniffed and altered in the middle of a transmission path can be provided.
For example, when content is requested in accordance with an HTTP procedure, the DTCP_Source and DTCP_Sink devices respectively serve as an HTTP server and as an HTTP client to create a TCP/IP connection for HTTP, and initiate content transmission. The HTTP client requests content on an HTTP server in an operating process which is identical to that of normal HTTP. In response thereto, the HTTP server sends back the requested content as an HTTP response. The DTCP_Source uses content key Kc to encrypt the content requested by the DTCP_Sink, and transmits, on a TCP stream, packets which each include a header including a payload formed by the encrypted content, nonce Nc, and an E-EMI.
In addition, when the same encryption key is continuously used for the entirety of a very long stream, a possibility that the key may be decrypted increases. Accordingly, the DTCP_Source device updates content key Kc by incrementing nonce Nc by one in units of 128-MB content. Since, in the middle of a byte stream, nonce Nc is greatly changed, a content key confirmation procedure is necessary, and, for the DTCP_Source device, the DTCP_Sink device performs a procedure for confirming nonce Nc.
In addition, in a content transmission system for supporting copyright protection, it is necessary to specify a content attribute concerning content protection. In DTCP-IP, by using two mechanisms, that is, an E-EMI and Embedded CCI which are described in a protected content packet (PCP) header, transmission of copy control information associated with content can be realized.
Embedded CCI is copy control information that is transmitted as part (i.e., in a form embedded in a PCP payload) of a content stream to be encrypted. Although many content formats include fields allocated for CCI in a form associated with a stream, a CCI definition and format are unique for each content format. Embedded CCI is interpreted as having a meaning such as “Copy Never”, “Copy One Generation”, “No More Copies”, or “Copy Free”. Since tampering of a content stream is implementation of false decryption, the integrity of embedded CCI can be guaranteed.
E-EMI enables easy access and realizes security by representing copy control information concerning the content stream in the PCP header. By locating an E-EMI in an easily accessible location of a particular bit position of a PCP header in a plaintext state, the device can immediately identify the copy control information of the content stream, whereby it is not necessary to extract embedded CCI by decrypting the content transmission format. E-EMI is important to enable the realization of a bit-stream-storage device that is unable to recognize and decode a special content format such as that of digital VCR.
A proper source device complying with DTCP-IP selects a correct encryption mode in accordance with the characteristics of a content stream, and sets an E-EMI on the basis of the selected encryption mode. Also, a proper sink device selects a correct encryption mode which is specified by an E-EMI in a PCP header. Since the E-EMI is used for generating content key Kc, tampering of the E-EMI causes mismatch between content keys Kc in encryption and decryption modes. Thus, content decryption fails, thus maintaining security.
FIG. 31 illustrates an internal structure of a PCP header (see, for example, DTCP Volume 1 Supplement E Mapping DTCP to IP (Informational Version), Revision 1.1, V1SE.4.22 Modification to 6.3.3 Content Encryption Formats). In this structure, an E-EMI is a 4-bit field describing an encryption mode. Values of the E-EMI correspond to types of copy control information. The definitions of bit values are shown in the following table (see, for example, DTCP Volume 1 Supplement E Mapping DTCP to IP (Informational Version), Revision 1.1, V1SE.4.7 Modifications to 6.4.2 Encryption Mode Indicator (EMI)). In the table, nine E-EMI values unused are reserved for future extension.
TABLE 1E-EMIEncryptionValueModeCopy Control Information1100A0Copy never (CN)1010B1Copy-one-generation (COG) [Format-cognizant recording only]1000B0Copy-one-generation (COG) [Format-non-cognizant recording permitted]0110C1Move mode (Audiovisual)0100C0No-more-copies (NMC)0010D0Copy-free with EPN asserted (CF/EPN)0000N.A.Copy-free (CF)
As described above, the PCP header includes an E-EMI specifying the encryption mode and copy control information of content. These parameters are insufficient as copy control information for the purpose of content protection. That is, necessary copy control information may not be written in the 4-bit E-EMI field. For example, pieces of output control information, such as a parameter (Analog Protection System (APS)) concerning analog output control of content and a parameter (Image Constraint Token (ICT)) concerning a picture size in an output mode, are treated as elements of copy control information in DTCP. In this specification, the output control information is additional or extended copy control information and is also called “super-extended copy control information”. The pieces of copy control information are not written in the E-EMI. Thus, it is only possible to embed the pieces of copy control information as part of Embedded CCI.
Also, as one of copy control functions in DTCP, the “Cognizant Function” in which, instead of controlling copying simply in accordance with an E-EMI, when a device correctly recognizes the format of content and Embedded CCI (that is, in a “cognizant” case), a content processing method is controlled in accordance with the Embedded CCI is provided. By using the cognizant function, it is necessary to compare the E-EMI extracted from the PCP header and the Embedded CCI extracted from the PCP payload. Relationship between the Embedded CCI and the EMI are shown in the following table.
TABLE 2Embedded-CCIE-EMICFCF/EPNNMCCOG-AVCOG-AudioCNA0AllowedAllowedAllowedAllowedAllowedAllowedB1AllowedAllowedProhibitedAllowedAllowedProhibitedB0AllowedAllowedProhibitedAllowedProhibitedProhibitedC1ProhibitedProhibitedAllowedProhibitedProhibitedProhibitedC0AllowedAllowedAllowedAllowedAllowedProhibitedD0AllowedAllowedProhibitedProhibitedProhibitedProhibitedN.A.AllowedProhibitedProhibitedProhibitedProhibitedProhibited
However, DTCP-IP only prescribes that Embedded CCI is transmitted as part of a content stream. In the current DTCP-IP, there is no provision concerning an Embedded CCI configuration method other than a provision (see, for example, Digital Transmission Content Protection Specification Volume 1 (Informational Version), Revision 1.4, Appendix B DTCP_Descriptor for MPEG Transport Streams) in which a DTCP descriptor corresponding to Embedded CCI is inserted concerning MPEG transport streams. Although fields for transmitting an CCI in a form associated with a stream are allocated in many content formats including an MPEG format, it is actual that the definition and format of CCI are unique or differs for each content format.
Embedding of copy-control information in a PCP payload is insertion of copy-control information in content. Thus, inevitably, the description method of the copy control information is dependent on a content format and differs for each format. Therefore, when AV content is transmitted in encrypted form complying with DTCP-IP, it is necessary for the DTCP_Source device to perform transmission while changing copy control information for each format, and it is necessary for the DTCP_Sink device to prepare software or hardware for analyzing copy control information for each format. This results in an increase in device costs. In addition, when copy control information is embedded in an encrypted PCP payload, a problem occurs in that, at a receiving end, the copy control information is not extracted unless it is decrypted.